1. Field of the Disclosure
The technology of the disclosure relates to configuring and handling communications privileges in a domain/domain server for communications involving entities outside the domain.
2. Technical Background
Traditional switch-based phone communication systems provide simple mechanisms to allow a called party to control interactions with a calling party. For example, voice mail is one form of controlling interactions. If a called party does not answer a phone call from a calling party, the calling party may leave a voice mail for the called party. The called party phone calls may also be automatically directed to voice mail. In either scenario, the called party can retrieve the voice mail at their convenience and decide if a return phone call will be made to the calling party. Caller identification, also known as “caller id,” is another form of controlling interactions. The called party can review the caller id of the calling party to identify the calling party and decide if the calling party phone call will be answered.
The Internet provides an infrastructure for establishing communications using data packet-based communications between entities. The entities may be user devices. For example, Session Initiation Protocol (SIP) was developed as one signaling protocol that could be used for establishing communications sessions in an Internet Protocol (IP) network. Voice over IP was also promoted adopting SIP as one protocol of choice. With SIP and other Internet Protocols developed for Internet communications, users or entities are identified by their associated domains. Domain names are used as part of a simple identification label under the Domain Name System (DNS) to indicate in which domain a user or other entity is associated. Other identification information, such as a user identification tag or address, can be associated with a domain name to provide a complete identification of a unique user or entity. Thus, one method of a first user or entity requesting to establish communications with a second user or entity, is for the first domain of the first user or entity to request contact with a second domain associated with the second user. The first domain server can make a DNS server request to find the IP address of the second domain server associated with the second domain user or entity to be contacted so that communications can be established. Thereafter, the first domain server can send an invite to the second user or entity at the second domain. If the second domain determines that the second user or entity exists within its domain, the invite can be handed off from the second domain server to the second user or entity to establish communications with the first user or entity.
One problem with this architecture for IP communications is that an outside system can spam users or entities in a given domain. An outside system can randomly make up addresses for a given domain to unsolicitedly contact users or entities in the domain. In this regard, domain servers may employ enterprise application software (EAS) in enterprise system configurations executed on a domain server to address spam and decide which communications are to be forwarded to its users or entities within its domain. A common example involves email communications. Enterprise systems may discriminate which email communications are forwarded to an addressed user or entity in its domain based on the address and/or domain of the user or entity outside the domain requesting email communications. However, this poses an issue for interactive communications, such as voice and video communications, as examples. For interactive communications, parsing and filtering may not maintain the interactive nature and integrity of the communications. Further, it may be desired to filter communications differently between users or entities within the same domain as opposed to communications outside a domain. Thus because of these issues, many enterprise systems choose not to employ SIP or other IP signaling protocols for communications with other systems outside its domain. The rationale is the potential of being flooded with unwanted invites and having to provide different filtering configurations based on whether communications are within the domain or with entities outside of the domain.
In response, federated database systems or federation systems have been developed and deployed in enterprise systems. Federation systems allow an administrator to setup and predefine, or provision, security rules or privileges (“federation rules”) for IP communications from an outside domain to control relationships to users inside the domain of the enterprise system. For example, a federation system may be configured to allow SIP voice calls from an outside domain, but not allow SIP video calls from the outside domain. Further, these federation rules may be set on an individual user basis or particular groups or communities of users. A problem with federation systems is that over time, the federation rules become massive and difficult for administrators to maintain as a result of constant provisioning and relationships becoming outdated. The rules become too numerous and complex to effectively manage. Further, configuring communities of users often lacks enough granularity and often, multiple communal relationships are required, thereby requiring additional federation rules. Further, as federation rules are configured for additional outside domains with users or entities that are members of different domains, additional federation systems may be required to be deployed, further increasing complexity and federation rule maintenance issues.
Accordingly, there is a need for effectively and efficiently providing a way to configure and maintain privileges for interactive communications between users and entities within different domains that scales well as complexity increases.